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@ Techniques for analyzing and controlling 
operation of a system of cooperating processes. 
A library of system calls used by the processes 
is replaced by a dynamically-linked library 
vi^ich performs the system calls and also sends 
messages indicating that the system calls have 
been performed. The messages are received by 
a display system which responds to the mes- 
sages by making a graphical display showing 
the cun-ent state of the system of processes. 
The graphical display displays the system of 
processes as a tree. Nodes in the tree represent 
the processes in the system and resources such 
as files used by the processes ; edges in the tree 
represent relationships between processes and 
other processes or resources. Users may con- 
trol which system calls result in messages, may 
control the rate at which the display system 
responds to the messages, and may also control 
X cution of the processes. 



FIG. 4 
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Backgr und of the Invention 

Field of th Inventi n 

The invention concerns analysis and control of s 
systems and more nearly concerns analysis and con- 
trol of systems made up of processes executing in 
computers. 

Description of the Prior Art io 

An important part of building large systems is de- 
bugging, that is, detecting, analyzing, and correcting 
enrors in an implementation of the system. When a 
system is implemented by means of programs exe- 15 
cuting in computers, there are many tools available 
for debugging the programs. There are discovery pro- 
grams such as cia which help programmers under- 
stand how a program is organized and programs 
called debuggers, which permit the programmer to 20 
see what happens when a program being debugged 
is executed. Modern debuggers pemiit the progranrv 
mer to interactively control the execution of the pro- 
gram being debugged. An example of such a debug- 
ger is the GD6 debugger, available from the Free 25 
Software Foundation. Debuggers have further begun 
to use graphical interfaces to show information such 
as the call history of a program, events generated by 
distributed-memory parallel programs, or a trace of a 
parallel execution of a program. One example of such 30 
graphical interfaces may be found in Adam Beguelin, 
et al., 'Visualization and Debugging in a Heterogene- 
ous Environment", in: IEEE Computer, June, 1993, 
pp. 88-95. 

The discovery programs and debuggers just de- 35 
scribed are perfectly adequate for their task; how- 
ever, modern systems are typically implemented not 
just as sets of cooperating subroutines, but rather as 
sets of cooperating processes. For purposes of the 
present discussion, a process may be defined as the 40 
entity in a computer system which actually executes 
a program for a user. In many systems, the cooperat- 
ing processes execute on different computers. When 
a system is implemented as a set of cooperating proc- 
esses; debugging the system involves not only under- 45 
standing and debugging the individual programs exe- 
cuted by the processes, but also understanding and 
debugging the cooperation of the processes. The lat- 
ter tasks cannot be performed by the program discov- 
ery tools and debuggers just described. so 

Present-day computer systems provide only 
meager resources for d bugging systems made up of 
c operating processes. In computer systems employ- 
ing th UNIX perating system (UNIX is a r gistered 
trademark of UNIX Syst ms Laboratories), for exanv 55 
pie, there is a trace utility which outputs a list of the 
calls made by th process t the operating syst m. 
Ther ar also an files utility which tells th user 



what files a giv n process has open and a f user utility 
which identifies what processes are using a given 
fil . A drawback of even these meager debugging 
tools is that th y can only provide Informatbn about 
processes executing on a single processor and con- 
sequently only have limited usefulness in under- 
standing and debugging systems where the cooper- 
ating processes execute on different processors. 

It is an object of the present invention to over- 
come the above problems with debugging systems 
made up of cooperating processes by providing tech- 
niques which permit dose analysis and control of 
such systems. 

Summary of the Invention 

The techniques of the invention are embodied in 
a visual process manager. The visual process man- 
ager has two parts: a monitor which sends messages 
when the processes in the system execute operating 
system calls for operations such as creating a child 
process or accessing a resource such as a file, and 
a graphical display generator which generates a dis- 
play in response to the messages. The display shows 
the state of the system of processes and changes as 
required by the messages. The user can thus deter- 
mine from the display what is happening in the syst m 
of processes. The user can further employ a pointing 
device such as a mouse to control the display and 
even the system of processes. 

In the preferred embodiment, the display is a di- 
rected acyclic graph of nodes and edges. The proc- 
esses and the resources they access are nodes in the 
graph, and the edges connecting the nodes indicate 
relationships between the nodes. For exampi , a 
node representing a process is connected to the node 
for its parent by an edge, and the node for a file which 
is being accessed by a process Is connected to the 
node for the process by another edge. 

An important advantage of the visual process 
manager is that no alteration in the code executed by 
the processes is required. The monitor is implem nt- 
ed by means of a dynamically-linked library which re- 
places the library of operating system calls provided 
with the computer system with a new library which not 
only makes the system calls, but also generates the 
messages. Per-process masks in the monitor permit 
the user to indicate which system calls will result in 
messages, what the form of the messages should be, 
and whether the library routine for the system call 
should await acknowledgment from the user before 
continuing. 

While the pref rred embodiment employs th 
techniques disclosed h r in to analyze systems of 
proc sses, the techniques are gen rally applicabi 
and may b employed in any situation wh re a library 
of routines may b replaced by a dynamically^linked 
library of routin s which perform the same functi ns, 
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but also s ndm ssages as a side eff ct A particular 
advantage of the techniques is that a system may be 
analyzed without modification or recompilation of the 
system's application-level code. Other objects and 
advantages of the apparatus and methods disclosed 
herein will be apparent to those of ordinary skill in the 
art upon perusal of the following Drawing and De- 
tailed Description, wherein: 

Brief Description of the Drawing 

FIG. 1 is a conceptual drawing of a distributed 
computer system in which the present invention 
may be implemented; 

FiG. 2 is an example display generated by the in- 
vention; 

FIG. 3 is another example display generated by 
the invention; 

FIG. 4 is an overview of an implementation of the 
invention; 

FIG. 5 is a further example display generated by 
the invention; 

FIG. 6 is a diagram of a message employed in the 
invention; and 

FIG. 7 is a diagram of a graph data structure env 
ployed in the invention. 

Reference numbers in the Drawing have two 
parts: the two least-significant digits are the number 
of an item in a figure; the remaining digits are the 
number of the figure in which the item first appears. 
Thus, an item with the reference number 201 first ap- 
pears in FIG. 2. 

Detailed Description of a Preferred Embodiment 

The following Detailed Description will first de- 
scribe a system in which the Invention may be imple- 
mented, will then show how a preferred embodiment 
of the system appears to a user, and will finally de- 
scribe the implementation of a preferred embodiment 
in detail. 

A System in which the Visual Process Manager 
may be Embodied: FIG. 1 

FIG. 1 shows a conventional modern distributed 
computer system. Some number of processors 103 
communicate with each other via communications 
system 111 , which may be any system which permits 
messages to be sent between the processors 103. 
Executing programs on each processor are a number 
of processes 105. Processes 105 may send messag- 
es t other processes 105 ex cuting n the same or 
other processors 103; m ssages to process s exe- 
cuting on oth r processors 103 are sent via commu- 
nications system 111. Process s 109 may also ac- 
cess files 1 09 in persistent storage 107. The files may 
be on persistent storag 1 07 bel nging to the proces- 



sor 103 upon which th process 105 is executing or 
on p rsistent storage 1 07 belonging to another proc- 
ssor103. 

A user of the Visual Process Manager has a dis- 
5 play device 112 and input devices such as Iceyboard 
117 and mouse 119 connected to one of the proces- 
sors 103, in this case processr 103(a). By means of 
Iceyboard 117 or mouse 119, the user can provide in- 
puts to processor 103(a) in response to displays on 
10 display 113 on display device 112. More particularly, 
the user can employ mouse 119 to move pointer 115 
in display 113 and can use the buttons on mouse 119 
to provide command inputs. 

15 User View of the Visual Process Manager: FIGs. 
2, 3, and 5 

A user of the visual process manager will gener- 
ally be worlcing with a display like that shown in FIG. 

20 2. Graph 201 appears on display device 112. In most 
embodiments, processor 103 will be running a win- 
dowing system and graph 201 will appear in a window 
in display 113. Graph 201 is a directed acyclic graph 
which shows a system of cooperating processes 

25 which are executing on four computers. Each comput- 
er is represented by a cluster 203 with the name of the 
computer (for example, kiwi). Inside each cluster is a 
group of process boxes 205. Each process box 205 
represents a process 105 executing on the computer 

30 represented by the cluster. The number inside the 
process box 205 is the process kJentif ier (pid) for the 
process. The process Identifier is the number used by 
the operating system of computer 203 to identify the 
process. The character string is the name of the pro- 

35 gram currently being executed by the process. Thus, 
process 105 with pid 23087 is executing the gcc pro- 
gram. Processes 105 whose process boxes 205 con- 
tain ? are executing a process initialization program. 
The dotted edges 207 Indicate paront-child relation- 

40 ships between processes 1 05. A process 1 05 is a par- 
ent of another process 105 if the parent process exe- 
cuted the operating system command which created 
the other process 105. Thus, process 23086 is the 
parent of process 23088. 

45 Processes 105 may of course access files 109. 

The files appear in graph 201 as file ellipses 209. 
Each file ellipse 209 contains a character string which 
is the name of the file represented by file ellipse 209. 
When a process 105 has opened a file 109, there is 

50 a solid edge 213 connecting process box 205 for the 
process and file ellipse 209 for the file. If the process 
1 05 has pened the file for reading, there is an arrow- 
head at proc ss box 205;. if the process 105 has 
opened the file for writing, th re is an arrowhead at 

55 f il ellipse 209; if the file has be n opened for both 
reading and writing, there is an arrowhead at both 
endsofedg 213. 

Process s 105 communicat in th systems in 
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which th invent! n is employed by nneans of the 
pipes and sockets provided by the UNIX operating 
system. Pipes are used only for communications be- 
tw en processes executing on the same computer 
103 and sockets are used for communications be- 
tween processes executing on different computers 
103, In the case of the sockets, the communications 
actually travel via communications system 111 . Pipes 
and sockets appear in graph 201 as pipe circles 215 
and socket circles 211. A socket circle 211 contains 
the name of the computer which was the destination 
of the socket when it was created and the number of 
the port in the destination computer. Edges 213 are 
used with pipe circles 215 and socket circles 211 in 
the same fashion as with file ellipses 209: if the pipe 
or socket is open for writing, the arrowhead is at circle 
211 or 215; if the pipe or socket is open for reading, 
the arrowhead is at process box 205. In the version 
of the UNIX operating system in which the preferred 
embodiment is implemented, pipes are unidirectional; 
one process writes to the pipe and the other reads 
from the pipe; sockets, on the other hand, are bidir- 
ectional. 

Operation of the Visual Process Manager: FIGs. 
3 and 5 

In a preferred embodiment, the visual process 
manager consists of two main components, one of 
which monitors the processes in a system as they 
execute, and one of which receives messages from 
the monitoring component and generates a graph 201 
in response to the messages. The components in the 
preferred embodiment are a monitor based on the 
ndimehsional file system (nDFS), described in Glenn 
Fowler, Yennun Huang, David Korn, and Herman 
Rao, "A user-level replicated file system", in: USENIX 
Cincinatti 1993 Summer Conference Proceedings, 
pp. 279-290, 1993, and a display generator based on 
the programs dot, explained in Emden R. Gansner, 
Eleftherios Koutsof ios, Stephen C. North, and Kiem- 
Phong Vo, "A Technique for Drawing Directed 
Graphs", in: IEEE Transactions on Software Engin- 
eering, vol. 19, no. 3. March, 1993, and lefty, descri- 
bed in Eleftherbs Koutsofios and David Dobkin, 
"Lefty: a two-view editor for technical pictures, in: 
Graphics Interface '91, pp. 68-76, Calgary, Alta, 
1991. 

To commence operation of the visual process 
manager in a preferred emt>odiment, the user starts 
a first process which executes the display generator 
and a second process which xecutes the monitor. 
Each process has its own window in display device 
112. Once the second process is running, the user 
executes a setup command in the second process's 
sh II which specifies a log f il to which the monitor 
sends messag and from which the display generator 
is to tak its input and the operating system syst m 



calls which are to be monitored by the monitor. In a 
preferred embodim nt, a user may specify only proc- 
ess-relat d operating syst m calls, process-related 
operating system calls and file access related oper- 
5 ating system calls, and the two foregoing classes to- 
gether with I/O system calls. In the preferred embodi- 
ment, the process-related operating system calls are 
the UNIX fork, exec, and exit cialls, the file-access re- 
lated calls are open, dose, dup, and pipe, and the I/O 
10 calls are read and write. Once the foregoing setup 
command has been executed, the monitor begins 
sending messages to the log file read by the display 
generator and the current state of the process in 
which the setup command executes and that proo- 
fs ess's descendents may be displayed in graph 201. 
Thus, all that is required to monitor a given system of 
processes is to start the first process of the system as 
a child of the process in which the setup comand is 
executed. 

20 The display generator operates in two modes: 

real time and single step. In real time mode, the dis- 
play generator reads the messages in the log f il as 
the monitor places them in the log file; in single step 
mode, the system being monitored runs until it termin- 

25 ates, with all messages from the monitor being placed 
in the log file. Thereupon, the display generator reads 
the messages In the tog file. In a preferred embodi- 
ment, the nrK)de is specified by means of an option on 
the command which commences execution of the dis- 

30 play generator In either case, graph 201 is dynami- 
cally updated as messages are read from the log file. 

Operation of the display generator in either mode 
is controlled by a global menu which appears in graph 
201 when pointer 115 is not positioned over a node in 

35 graph 201 and the right mouse button is pressed. FIG. 
3 shows a global menu 301 for the real time mode. 
The menu options are the following: 

• do layout: redo the layout of graph 201; 

• redraw: refresh the graph; 

40 • save graph: save the graph to a file; 

• zoom in: enlarge the graph; 

• zoom out: reduce the graph; 

• cleanup: removes nodes representing dead 
processes from graph 201 ; 

45 • find node: scroll the display so that a node spe- 
cified by pid or name is at the center of the dis- 
play of graph 201; 

• start/stop: stop updating the graph until the 
item is selected again; 

50 • text view: look at the program currently being 

interpreted by the display generator; and 

• exit end ex cution of the display generator. 
Options are selected by using the mouse to move 
pointer 11 5 to the desired entry in the menu and de- 

55 pressing the left mouse button. When graph 201 is 
larger than th window in which it is being displayed, 
the user may employ scroll bars on the window to 
bring undisplay d porti ns of th graph into the win- 
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dow. 

The global m nu f r single-step mod differs 
from the menu for real-time mode in that start/stop 
and cleanup are replaced by the following two s lec- 
tions: • 5 

• play non-stop: the display generator will re- 
spond to the messages in the log file without 
stopping; and 

• ptay until: the user may specify a system call 
name or a message sequence number; the dis- io 
play generator will respond to messages in the 

log file until the named system call or the spe- 
cified message in the sequence is reached. 
When neither play non-stop nor play until has been 
selected, the user controls the rate at which the mes- is 
sages are read with the mouse: when the user clicks 
with the left-hand button, the next message is read 
and graph 201 modified accordingly. Single-step 
mode thus gives the user the option of viewing only 
those portions of the operation of the system of proc- 20 
esses in which he is interested. 

Menus for the nodes of graph 201 permit the user 
to find out information about individual nodes and in 
the case of process boxes 205, to manipulate the 
processes. To obtain a node menu, the user moves 25 
pointer 115 to the desired node and clicks with the 
right mouse button. The contents of a node menu de- 
pend on the kind of node and on whether the display 
generator is operating in real time or single step 
mode. FIG. 5 shows node menu 501 for process box 30 
6678 in real time mode. The possible menu selections 
are the following: 
. • print entry: print Information about the entity 
represented by the node; in a process node, 
the information includes the node kind, the id 35 
of the machine the process is running on, the 
name of the machine, the process's pid, and 
the pathname of the program being currently 
executed by the process; 

• print attributes: print the display attributes for 40 
the node, for example its color, shape, font 
name, and font size; 

• kill: execute the UNIX operating system kill 
command on the process to terminate it; the 
process may ignore the command; 45 

• kill -9: execute kill in a form which requires that 
the process be terminated; and 

• run dbx: run a debugger on the program being 
executed by the process. 

In single-step mode, only the print entry and print attr so 
selections are available. 

The m nus for file ellipses 209 include only the 
print entry and print attr set ctions in both modes; 
when print entry is s lected, th file's name, device 
name and inode nam are display d. The menus for 55 
pipe and sock t circles 211 include thos s lections, 
and additionally a show m ssage selection, which 
shows the messages passing through the s lected 



pip or socket when the monitor is monitoring I/O sys- 
tem calls. With print entry for a pipe, the identifier is 
displayed by which each process using the pipe 
knows the pipe and with sockets, the sockef s name 
and the source and destination machine names and 
ports are displayed. 

Detailed Implementation: Figs. 4, 6, and 7 

An overview of an implementation of the prefer- 
red embodimentof the visual process manager is giv- 
en in FIG. 4. Visual process manager 401 has the two 
main components previously discussed: monitor418, 
which monitors the behavior of the processes 1 05 be- 
longing to the system being studied, and display g n- 
erator 419, which generates display 201 on display 
device 113 and responds to inputs from keyboard 117 
and mouse 119. Communication between the compo- 
nents occurs in a preferred embodiment via log file 
411, into which monitor 418 writes messages 406 re- 
ceived from the processes 105 being monitored and 
from which display generator 41 9 reads the messag- 
es. 

Monitor 418 

Continuing in more detail with monitor 418, Its 
components consist of a message generator 403 for 
each process 1 05 belonging to the system being stud- 
ied and a back end server process 409. Message 
generator 419 generates messages when the proc- 
ess 105 performs the system calls being monitored. 
Back end server process 409 receives the messages 
from the processes 105 and writes them to log fil 
411. Communication between the processes 105 and 
back end server 409 is by means of sockets provided 
by the UNIX operating system. 

As described in detail in the Fowler, et al. article 
cited above and in Fowler, et al., U.S. Patent Applica- 
tion Ser. No. 08/0037, User-Level Replicated File 
System, filed 6/18/93, message generator 403 is inrv 
plemented by dynamically linking each process 1 05 to 
the executable code for a set of library routines. The 
process 105 being monitored executes the dynami- 
cally-linked code in place of the code for the standard 
system calls provided by the UNIX operating system. 
The dynamic linking occurs when the process is ini- 
tialized. Because the executable code is dynamically- 
linked at process initialization, there is no need to al- 
ter or relink the application code being executed by 
the process. A detailed discussion of dynamic linking 
may be found in Shared Libraries, Sun Microsystems, 
Inc., Mountain View CA, 1988. 

The code in the library routines for a given UNIX 
system call invokes the system call; in addition, how- 
ev r, it produces sid effects. In the visual process 
manager, the side effects include the messages 406. 
FIG, 6 shows the details of a message 406. Th mes- 
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sag includes the following fields: 

• source pid (SPID) 601, th pid of the process 
1 05 which made the system call which resulted 
in the message; 

• source machine (SMACH) 603, an identifier for 5 
the computer on which process 105 is execut- 
ing; 

• system call name (Syscall Name) 605, the 
name of the system call made by the process 
105; 10 

• system call arguments (Syscall Args) 607, the 
arguments of the system call made by the proc- 
ess 105; and 

• system call results (Syscall results) 609, the re- 
sults of the system call made by the process is 
105. 

In a message 406 for an open system call, for exanv 
pie, the arguments 607 include the pathname of the 
file to be opened and the nnode in which it is opened, 
and the result 609 includes the newly-opened file's 20 
device number and inode number. 

As indicated above in the description of the user 
view of the visual process manager, a user may spec- 
ify in the set up command which types of system calls 
are to be monitored. That information is stored in a 25 
mask 405 for each process 105. The routines in the 
dynamically-linked library check mask 405 for a proc- 
ess 1 05 before sending a message and send the mes- 
sage 406 only if the mask 405 indicates that the mes- 
sage is to be sent for that dass of system calls. In the 30 
preferred embodiment, masks are set In the set up 
command and and are set for classes of system calls; 
the masks are then inherited by all of the processes 
being monitored. In other embodiments users may 
employ the menus to set masks for individual proc- 35 
esses and system calls. The preferred embodiment 
additionally includes a "terse" mask which may be 
specified with system calls that return strings. When 
the terse mask is not set for the system call, the sys- 
tem call returns the string in message 406; when the 40 
terse mask is set, the system call returns a pointer to 
the string. Once a process's mask is set, either via the 
set up command or interactively, it is inherited by the 
process's descendents. 

45 

Display Generator 419 

Display generator 419 is implemented as two 
processes, a message interpretation process 41 5 and 
a graph generating process 417. In a preferred env 50 
bodiment, the message interpretation process 415 
executes the lefty program, described in the Koutso- 
fios reference cited above, and the graph g nerator 
process 417 executes the dot program, describ d in 
th North r ference cited abov . 55 

Messag interpreter 415 reads messages 40B 
from log file 411; in r al-time mode, it reads the mes- 
sages 406 as back nds rver 409 writes th messag- 



es to tog file 411; in single-step mode, message inter- 
preter 41 5 b gins reading messages 406 from log file 
411 only after the processes 105 in the system being 
monitored have all terminated. For each message, 
message interpreter 415 determines the type of sys- 
tem call from the message 406 and makes the 
changes required in graph data structure 421. which 
represents graph 201 , by the niessage. If there are no 
more messages 406, or if a given number of messag- 
es 406 have been processed since the last redraw, 
display 201 is redrawn. What happens when graph 
201 is redrawn depends on the kind of changes re- 
quired by the messages406. If the changes do not re- 
quire a new layout of graph 201, message interpeter 
415 simply takes information from graph data struc- 
ture 421 and provides it to windowing system 427, 
which uses the information to actually display graph 
201 on display device 112. If the changes do require 
a new layout, message interpreter 41 5 takes the infor- 
mation required for the new layout from graph data 
structure 421 and provides it to graph generator 417 
as logical graph description 423. Graph generator 423 
returns a physical graph description 425 based on the 
logical graph description to message interpreter 41 5; 
message interpreter 415 then Incorporates the new 
physical graph description into graph data structure 
421, and provides information from the updat d 
graph data structure 421 to windowing system 427 as 
described above. 

FIG. 7 provides details of graph data structure 
421 . Graph data structure 421 has two main compo- 
nents, node array 701, which contains a node entry 
703 for each node in graph 201 , and edge array 71 3, 
which contains an edge entry 715 for each edge In 
graph 201. Each node entry 703 contains four kinds 
of information: 

• logical node information 705, which messag 
interpreter 415 provides as logical graph data 
423 to graph generator 41 7; 

• node display infonmation 707, which graph 
generator 417 provides to message interpreter 
415 as physical graph data 425 in response to 
logical graph data 423; 

• visual process manager information 709; and 

• edge pointer list 711. 

The visual process manager information 709 is the in- 
formation which appears in the node in display 201 
and in the menu associated with the node repres nt- 
ed by node entry 703. The edge pointer list 711 con- 
tains a pointer to each edge entry 715 for an edge 
which begins or terminates at the node represent d 
by node entry 703. 

Edge entry 715 contains the same dass s fin- 
formati n for each dg . Logical edge information 
717 contains the informati n about the edge which 
message interpr ter 41 5 provided to graph g n rator 
417; dg display information 719 contains the infor- 
mation riBturned by graph gen rator 41 7 to m ssage 
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interpret r415;VPM info 721 is the information which 
appears in the menu associat d wth th edge; 
fromjptr 723 is a p int r to the node entry 703 in 
node array 701 which is the source of the edge; to_ptr 
725 is a pointer to the node entry 703 in node array 5 
701 which is the destination of the edge. 

A limitation of monitor 41 8 as implemented in the 
preferred embodiment is that message interpreter 
415 cannot always telt from messages 406 whether a 
process 105 has died. In a preferred emt)odiment, io 
that problem is dealt with by having message jnterp- 
eter 41 5 keep track of the time since the last message 
from a given process 105. If a certain time limit is ex- 
ceeded, message intepreter 41 5 queries a pid server 
429 on the computer the given process was running is 
on to determine whether the process 105 is still alive. 
If it is not message interpreter 415 removes the infor- 
mation for the process 105 from graph data structure 
421, and oh the n^xt redraw of graph 201 the node for 
the process 105 and the nodes for any files or pipes 20 
accessed solely by the process will disappear. 

Message interpreter 415 further deals with inputs 
from keyboard 117 and mouse 119, as provided by 
windowing system 427. For example, when a user 
presses the right mouse button to request a global 25 
menu or a node menu, message interpreter 415 de- 
termines what type of menu is required and provides 
the infonnriation for the menu to windowing system 
427, which displays the window. Similarly, when a 
user selects a menu entry which requires display of 30 
information, windowing system 427 indicates that the 
selection has been made and message interpreter 
415 obtains the infonmation from graph data structure 
421 and provides it to windowing system 427 for dis- 
play. When a user selects the kill entry on the node 35 
menu for a specif ic process, message interpreter 41 5 
executes the system command which kills the proc- 
ess 105. 

An Interactive Version of visual Process 40 
Manager 401 

In the preferred embodiment, a user at the termi- 
nal can only determine the rate at which messages in 
log file 411 are read by message interpreter 415; he 45 
cannot control the execution of the processes in the 
system by means of visual process manager 401. In 
another embodiment, the user may employ visual 
process manager 401 to actually control execution of 
the system of processes. In this embodiment, log file so 
411 is replaced by a socket 420 which directly con- 
nects back nd s rv r 409 to messag interpreter 
415; further, bidirectional sockets 416 now connect 
back nd s rv r 409 with the messag gen rators 
403 for the processes 105 b ing monitored. 55 

Changes are also required in message 406, mask 
405, and the cod for the dynamically-linked library. 
Message 406 now carries an additional field, ACK 



field 611, which indicates whether message interpret- 
r 41 5 has to acknowledge a message r ceiv dfrom 
back end server 409. Mask 405 now includes an ac- 
knowledgement mask which indicates on a per-sys- 
tem call basis which system call requires acknowl- 
edgement. Finally, the dynamicajly-l inked library rou- 
tines are modified to include code which examines 
the acknowledgement mask before sending the mes- 
sage. If the mask indicates that the system call re- 
quires acknowledgement, the library routine which re- 
places the system call sets acknowledgement field 
611 in the message and waits for an acknowledge- 
ment message from back end server 409; only after 
the message anrives does the library routine conn- 
plete its execution. 

Operation of the interactive mode is as follows: To 
place a process 105 in the mode, a user employs 
mouse 119 as previously described to obtain the 
menu 501 for the process. The menu 501 contains an 
additional entry, specifying interactive mode. Wh n 
the user selects the entry, another menu appears 
which permits the user to specify which system calls 
are to be acknowledged for that process. Messag in- 
terpeter 415 takes the input from the menu and sets 
fields for the node indicating what system calls are 
currently being acknowledged. Message interpr ter 
415 also sends a message via socket 420 to back end 
server 409 specifying the process 405 in which sys- 
tem calls are to be acknowledged and the system 
calls to be acknowledged. Back end server 409 then 
sends a message via socket 416 to the specif i d 
process 105. and code in message generator 403 
respnds to the code by setting the acknowledgement 
mask as required by the message. 

From the time the acknowledgement mask is set, 
system 401 operates as follows: when process 105 
executes a system call, the library routine for the sys- 
tem call checks acknowledgement mask 405 for the 
system call. If the mask is set, the message 406 has 
its acknowledgement field 611 set and the library rou- 
tine pauses after executing the system call and s nd- 
ing the message 406. When the message arrives via 
socket 416, back end server 409, and socket 420 in 
message interpreter 41 5, message interpreter41 5 re- 
sponds to the set acknowledgement field 611 by 
changing graph 201 as required by the message 406 
and changing the appearance of process box 205 for 
the process, in the display to show that th process 1 05 
represented by process box 205 is waiting for an ac- 
knowledgement. The user provides the acknowledge- 
ment by moving pointer 115 to the process box 205 
and clicking with the left button. In response to th 
position of point r 115 and the click of the left button, 
message int rpreter415s nds an acknowledgement 
message via sock t 420. backend server 409, and 
socket416 to message generator 403 forthe proc ss. 
Inresp nsetothem ssage.th library routine finish- 
es its execution. Whil this is going on, m ssage in- 
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terpreter 415 further chang s the appearance of 
graph 201 to indicate that the process is no longer 
awaiting acknowledgement 

As will be dear from the foregoing, the user of 
system 401 can control execution of a process 401 to 
any desired degree of granularity. Other embodi- 
ments may also include an entry in global menu 301 
permitting global setting of acknowledgement masks. 

Conclusion 

The foregoing Detailed Description has disclosed 
to those of ordinary skill in the arts to which the inven- 
tion pertains the best modes presently known to the 
inventors for implementing their visual process man- 
ager. However, as already pointed out, the techniques 
used to implement the visual process manager are by 
no means limited to the analysis of systems of proc- 
esses, but may be used in any system in which a li- 
brary used by the system may be dynamically re- 
placed by another library. 

As wilt further be immediately apparent to those 
skilled in the relevant arts, there are many other ways 
of implementing the visual process manager dis- 
closed herein. For example, the dynamic linking and 
graph drawing techniques disclosed herein are partic- 
ularly advantageous for implementing the invention, 
but the library routines in monitor 418 could be stati- 
cally linked to the code executed by the processes 
and graph drawing programs other than lefty and dot 
could be employed to implement display generator 
419. The selection of operating system calls to be 
monitored wilt vary from operating system to operat- 
ing system and may also vary according to the appli- 
cation for which the visual process manager is intend- 
ed. Similarly, the kinds of masking available may dif- 
fer from implementation to implementation. 

In the same vein, the shapes, labels, and colors 
used in graph 201 in a preferred embodiment are all 
particularly advantageous, but other embodiments 
could employ other shapes and other colors and may 
also make different decisions concerning what infor- 
mation is shown directly on a node and what is acces- 
sible by menu. Further, other embodiments may offer 
the user more or less control of display 201 or of the 
operation of the system of processes, and may also 
employ different techniques for commencing execu- 
tion of the system. Because the above is the case, the 
foregoing Detailed Description is to be considered in 
all respects exemplary and illustrative, but not re- 
strictive, and the full scope of the invention disclosed 
herein is not to be determined from the D tailed De- 
scription, but ratherf rom the attached claims as Inter- 
preted with the full breadth permitted by th patent 
laws. 



Claims 

1. Apparatus for analyzing a system of processes 
comprising: 

5 monitoring means for causing at least one 

of the processes to send a message as a side ef- 
fect of an operating system call perfomted by the 
process; and 

means for generating a graphical display 

10 indicating the state of the system of processes. 

2. The apparatus set forth in claim 1 wherein: 

the graphical display displays the system 
of processes as a directed acyclic graph wherein 
15 the processes and resources used by the proc- 
esses are nodes in the graph. 

3. The apparatus set forth in claim 1 wherein: 

the monitoring means further comprises a 
20 routine which makes the operating system call 

and sends the message. 

4. The apparatus set forth in claim 3 wherein: 

the routine is dynamically linked with a 
25 program executed by the process. 

5. The apparatus set forth in claim 3 wherein: 

the monitoring means further comprises 
masking means for determining how the routin 
30 deals with the message; and 

the routine which makes the operating 
system call further deals with the message as in- 
dicated by the masking means. 

35 6. The apparatus set forth in claim 5 wherein: 

the masking means includes first masking 
means which indicates whether the message is to 
be sent. 

40 7. The apparatus set forth in claim 5 wherein: 

the masking means includes second 
masking means which indicates a form for the 
message. 

8. The apparatus set forth in claim 5 wherein: 
the monitoring means is capable of receiv- 
ing an acknowledgement message; 

the masking means includes third masking 
means which indicate whether the sent message 
is to be acknowledged; and 

the routine which makeis the operating 
system call responds to the third masking m ans 
whenth sentm ssag istob ackn wiedgedby 
indicating therein that the sent m ssage is to be 
acknowl dged and awaiting the acknowledge- 
m nt message. 

9. The apparatus s t forth in claim 5 wherein: 
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there is a masking means corresponding 
to ach one of the process s. 

10. The apparatus set forth in claim 9 wherein: 

a child process receives a copy of the 5 
masking means corresponding to its parent 

11. The apparatus set forth in claim 9 wherein: 

the monitoring means is capable of receiv- 
ing a mask message and responding thereto by io 
causing the masking means to determine accord- 
ing to the mask message how the routine deals 
with the sent message. 

12. The apparatus set forth in claim 1 further com- is 
prising: 

means for controlling the manner in which 
the means responsive to the messages responds 
to the messages. 

20 

13. The apparatus set forth in claim 12 further com- 
prising: 

means for receiving the messages from 
the monitor means; 

and wherein 25 

the means responsive to the messages 
reads the messages from the means for receiving 
the messages; and 

the means for controlling the manner in 
which the means responsive to the messages re- 30 
sponds to the messages does so by controlling 
how the means responsive to the messages 
reads the messages. 

14. The apparatus set forth in daim 1 further conv 35 
prising: 

means responsive to a user of the appara- 
tus for sending a control message; and wherein 

the monitoring means further responds to 
the control message by causing the process to 40 
behave as required by the control message. 

15. The apparatus set forth in claim 14 wherein: 

the monitoring means further comprises a 
routine which makes the operating system call 45 
and sends the message; and 

the routine waits for the control message 
to finish execution. 

16. The apparatus set forth in claim 15 wherein: so 

the monitoring means includes masking 
m ans which indicat whether the sent message 
is to be ackn wiedged; and 

th routine which makes the operating 
system call responds to the masking means when 55 
the sent message is to b acknowledged by indi- 
cating therein that the sent messag is t be ac- 
knowledged; 



the means responsive to the sent mes- 
sage r sponds thereto when the sent message is 
to be acknowledged by pr vidlng an indication 
thereof to the user; and 

the user sends the control message in re- 
sponse to the indication. 

17. Apparatus for analyzing a system of processes 
comprising: 

means for causing at least one of the proc- 
esses to send a message when creating a child 
process or accessing a resource; and 

means responsive to the message for gen- 
erating a graphical display which displays the 
system of processes as a directed acyclic graph 
wherein the processes and resources used by the 
processes are nodes in the graph. 

18. The apparatus set forth in claim 2 or 17 wher in: 

a first edge in the graph indicates a rela- 
tionship between one of the processes and one 
of the resources. 

19. The apparatus set forth in claim 2 or 17 wher in: 

a second edge in the graph indicates a re- 
lationship between a first one of the process s 
and a second one thereof which is a descendent 
of the first one. 

20. The apparatus set forth in claim 2 or 17 wher in: 

the processes in the system execute on 
one or more processor; and 

the nodes for processes executing on a 
given one of the processors belong to a cluster 
representing the given processor. 

21. The apparatus set forth in claim 2 or 17 wherein: 

A node's shape indicates whether the 
node represents one of the processes or on of 
the resources. 

22. The apparatus set forth in claim 21 wherein: 

the resources include file resources and 
corhmunications resources; and 

the nodes for the file resources have a first 
shape and the nodes for the communications re- 
sources have a second shape different from the 
first shape. 

23. The apparatus set forth in claim 2 or 17 wherein: 

the message is one of a sequence ther of; 

and 

the means for g nerating the graphical 
display alters the graphical display as r quired by 
the messag . 

24. Analysis apparatus for analyzing operation of a 
system which is implemented in a computer and 
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which uses a first library of first routines, th ap- 
paratus comprising: 

a second library of second routines which 
perform the same functions as the first routines 
and additionally generate messages indicating 5 
changes in the system; 

means for dynamically replacing the 
executable code for the first library with the 
executable code for the second library; 

masking means accessible to the second io 
routines which indicate how the second routines 
generate the messages, the second routines re- 
sponding to the masking means by generating 
the messages as Indicated therein; and 

means responsive to the messages for is 
outputting a state of the system. 

25. The analysis apparatus set forth in daim 24 
wherein: 

the state of the system is output as a 20 
graphical display of the system. 

26. The analysis apparatus set forth in daim 25 
wherein: 

the graphical display of the system dis- 25 
plays the system as a directed acyclic graph 
wherein entities in the system appear as nodes in 
the graph and relationships between entities ap- 
pear as edges in the graph. 

30 

27. The analysis apparatus set forth in claim 24 fur- 
ther comprising: 

means whereby a user of the analysis ap- 
paratus provides a control message therefor; 

and wherein 35 

the second library indudes a control mes- 
sage receiving routine; and 

the second routines are responsive to the 
control message. 

40 
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